This section is intended to provide a background or context to the invention that is recited in the claims. The description herein may include concepts that could be pursued, but are not necessarily ones that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, what is described in this section is not prior art to the description and claims in this application and is not admitted to be prior art by inclusion in this section.
In recent years, mobile broadcast solutions have been standardized by different organizations, such as the 3rd Generation Partnership Project (3GPP) MBMS. 3GPP MBMS enables resource-efficient delivery of multimedia content to the mobile users. A MBMS client can receive content via download delivery, streaming delivery, a combination of streaming delivery and download delivery, and/or other delivery methods.
MBMS is a 3GPP Release 6 (Rel-6) feature which may be deployed by operators only in a few areas where it is cost efficient to have the broadcast/multicast distribution of content. When MBMS subscribers move to other areas where there is no MBMS coverage, the operator may distribute the MBMS content in a unicast mode. However, application/transport layer signaling is required to ensure unicast mode reception of MBMS content to the subscribers while the subscribers are roaming in MBMS-outage areas.
Therefore, application/transport signaling and optimization techniques are needed for such scenarios. One of the objectives of the 3GPP SA4 Release 7 (Rel-7) work item on MBMS User Service Extensions is to specify the application/transport layer signaling needed for MBMS content distribution in unicast mode (over streaming and interactive bearers). Another objective is to specify optimization techniques for MBMS content delivery. Table 1 below shows the mapping between protocols to be used in broadcast/multicast and unicast modes as specified in MBMS Rel-7:
TABLE 1Download onlyStreaming onlyStreaming + DownloadDelivery MethodDelivery MethodDelivery MethodsMBMS ContentFile Delivery overMBMS StreamingMBMS StreamingDistribution usingUnicast TransportFrameworkFrameworkBroadcast/Multicast(FLUTE)/UserReal-timeRTP/UDP forBearersDatagram ProtocolTransport Protocolmedia transport(UDP)(RTP)/UDP forRTP/UDP for FECmedia transporttransport +RTP/UDP forFLUTE/UDP for fileForward ErrordownloadCorrection (FEC)transportMBMS ContentOpen MobilePSSPSS EnhancementsDistribution usingAlliance (OMA)-Real-time(PSSe)Unicast BearersPUSH for FileTransport SessionRTSP for session(For roamingDelivery TableProtocol (RTSP)controlMBMS clients)(FDT) transferfor session controlRTP for mediaHypertextRTP/UDP fortransportTransfermedia transportFLUTE/UDP for fileProtocol (HTTP)download in the sameGET requestsRTSP sessionfor individualfiles
When a MBMS client moves from a MBMS coverage area to an MBMS outage area, an ongoing MBMS streaming session is mapped onto a new PSS session. Unlike MBMS streaming sessions, PSS sessions provide session and media-level control to the client. The client can request the PSS transmission to start from any point on the media timeline by using the appropriate value in the Range header of the RTSP PLAY request.
Due to the change of bearers from MBMS to PSS, the client experiences an interruption in the media delivery. It is desirable that the user perceived interruption be minimized or controlled according to the user preferences. However, required signaling mechanisms are currently not defined in the current MBMS and PSS specifications.
FIG. 1 is a depiction of a hybrid MBMS-PSS service. As shown in FIG. 1, MBMS user equipment (UE) 110 receives the same service over MBMS bearers (when it is in an MBMS-coverage area) and over PSS bearers (when it is not in an MBMS coverage area). When the MBMS UE is roaming in an MBMS outage area, it receives the service over a unicast bearer from a PSS server 120. When the MBMS UE 110 is in a MBMS coverage area, it receives the service over an MBMS bearer from a broadcast multicast service center (BM-SC) 130. The BM-SC 130 and the PSS server 120 may be collocated or connected.
When the bearers change from MBMS to PSS, the media playback can start from any instant in the media timeline. As mentioned above, he precise instant in the media timeline depends on the Range header field of the RTSP PLAY request from the client. For example, the client can request media playback beginning with the precise instant where the media reception over MBMS bearers had stopped. Alternatively, the client can request media playback from the current instant of the media stream. In other scenarios, the client can request media playback from a few seconds before the instant where the media reception over MBMS bearers had stopped. FIGS. 2(a)-2(c) visually depict these different scenarios. In FIG. 2(a), media playback begins from the current instant of the media stream, resulting in the user not observing some of the media playback during the PSS setup delay. In FIG. 2(b), media playback begins with the precise instant where media reception over MBMS bearers had stopped. In FIG. 2c), media playback begins from a point before which media reception over MBMS bearers had stopped, resulting in a slight overlap in the media timeline. It should be noted that options other than these three presented scenarios are possible.
Some hybrid MBMS-PSS services might not support each of the above options. Additionally, even if a particular hybrid service supports all three options, the user may prefer to use one of these three options, or yet another option, (depending on the content type and personal preferences, for example). The support of different playback options might be signaled to the user, whose preference or choice is to be signaled to the BM-SC. In the current MBMS Rel-7 and PSS Rel-7 specifications, for example, the required signaling between the BM-SC and the MBMS UE is not specified.
As another example, the current version of the MBMS specification (i.e., 3GPP TS 26.346-740) considers the usage of the same synchronization source (SSRC) for the RTP streams of the corresponding media in both MBMS and PSS sessions. This ensures continuity in the sequence number and time-stamp series for the RTP packets received via MBMS and PSS bearers. However, this arrangement fails to consider the delays that are incurred during the PSS session setup phase which occur before the RTP/RTCP packet reception in PSS. This delay can be in the order of several seconds.